2. Requirements Analysis/Domain Models

Return to TOC

Requirements Engineering

• artifact: any work product produced and used during a project
  • user story, iteration plan, vision (priorities), DCD (design class diagram, type of UML)
• domain: targeted subject area of program/what the software is about
  • OSCAR's domain: course registration

Do we need documentation?
Agile: focuses on working software over documentation
XP: not necessarily; write code if problem is understood

Traditionally, a Product Requirements Document (PRD) is used. Can specify:

• Functional Requirements (FRs)
  • things it has to be able to do
• Non-functional requirements (NFRs)
  • usability, security, reliability, performance

These requirements can be defined by stakeholders, the application domain, and documentation

Requirements Analysis

• Verification
  • check that the product is being built right
  • each step yields the right products
• Validation
  • check that the right product is being built
  • requirements will satisfy stakeholders
  • acceptance document
    • agreed-upon set of conditions such that if all are satisfied, the software should be accepted

requirements prioritization: requirements are negotiated based on importance due to limited time/resources
Requirements should also have a time estimate and be identifiable (eg numbered)

Domain Model

a diagram with concepts/domain objects, their attributes, and connected by lines representing their associations
used to understand the problem- does not model software classes

• Creating a DM:
  • identify nouns/noun-phrases as candidates for conceptural classes or attributes
  • Report Objects (e.g. a receipt in a store transaction) may be exluded if they do not have some other functionality that needs to be modeled
  • If we do not think of some conceptual object as a number or text, it is probably a conceptual class
  • description classes (those that describe something else) may be useful when there needs to be a description independent of the current existance of the object, or reduces redundant/duplicate information
  • associations demonstrate a meaningful/interesting connection between classes
    • generally read bottom-up, right-to-left
    • sometimes a direction arrow is included when there are exceptions
    • commonly verb phrases (paid-by instead of uses)
  • names should follow ClassName-VerbPhrase-ClassName format, where the verb phrase creates a readable and meaningful phrase